\subsection{Creating the service}
We used \emph{eclipse} for the web service development so here are some important steps we followed. We decided to use Tomcat because is the 
most known web service server, from \emph{apache}. This is supposed to be reliable, well documented and easy to look for help in Internet. We 
chose the latest version, \emph{Tomcat 7}, because it was needed to \emph{Axis 2.2} version we already had, previous version would not work at all.
After downloading the Tomcat server from \emph{http://tomcat.apache.org/} and uncompressing it in a folder, but also the eclipse should know 
that server is available. In order to do this we had to go to \emph{Preferences - Servers - Runtime Environments} and add the \emph{Tomcat 7} 
server indicating the eclipse where the server folder is.

Later we created a new "\emph{Dynamic Web Service}" project where we created the packages model, database and controller. We located the 
classes mentioned in the model in the "\emph{model}" folder. Those which have to do with the database fit into the database package, like the 
interface and the implementation for \emph{MySQL}. Finally the classes that have to do with the web service are located in the controller 
package. Of course we have also a testing main function where we can use it for testing while developing. Finally, this is the structure we 
have in the project:

  \begin{figure}[ht]
    \centering
    \includegraphics[keepaspectratio, width=0.7\textwidth]{WebService/images/fflServer.png} 
    \caption{\emph{fflServer} project}
    \label{ws-fflServer}
  \end{figure}

Now that everything is ready we can take as an example a simple function like \emph{exists} that checks whether a user nick has already been 
used and returns the result to the client. This is how it looks like the function in the \emph{FFLocationAPI} class, the public service class.

\begin{lstlisting}[captionpos=b,label=ws-exists_java, caption={\textit{The "exists" function's source code}},language=Java, 
basicstyle=\small, frame=single]
public boolean exists(String nick) {
  return dbc.exists(nick);
}
\end{lstlisting}

The Web service function takes one parameter, the nick string that goes directly to the database to check if it exists, and it returns the 
result as a boolean.

If we run the Web service by selecting this \emph{FFLocationAPI} and choosing "\emph{Run on a Server}" we will get a set up menu. The most 
interesting parts are choosing the server and which methods do you want to publish in the web service. The server choice is quiet easy at 
this point, we choose to create a \emph{Tomcat7} server to run this web service, and we can check all the methods in the class to be published.
Then eclipse creates a \emph{WSDL} with the web service's specifications. Later on every specification, description or message is 
going to follow the \emph{SOAP} protocol, so everything is going to be in \emph{XML} format. An important fact is to know where the methods 
are published, in which workspace, because the client should match this, that is why the \emph{WSDL} start like this:

\begin{lstlisting}[captionpos=b,label=ws-wsdl_header, caption={\textit{WSDL file header}},language=XML, basicstyle=\small, frame=single]
<wsdl:definitions targetNamespace="http://controller">
\end{lstlisting}

Later we can see how each method is described, let say the \emph{exists} function. This method is called "\emph{exists}" and the only parameter 
it takes is one called "\emph{nick}" and that is a string type.

\begin{lstlisting}[captionpos=b,label=ws-exists_request, caption={\textit{Exists method's invocation}},language=XML, 
basicstyle=\small, frame=single]
<element name="exists">
  <complexType>
    <sequence>
      <element name="nick" type="xsd:string"/>
    </sequence>
  </complexType>
</element>
\end{lstlisting}

As you can see this information in the \emph{WSDL} is enough to build a \emph{SOAP} message with a request. If we continue reading the 
\emph{WSDL} we find the information about the functions response. 

\begin{lstlisting}[captionpos=b,label=ws-exists_answer, caption={\textit{Exists method's response}},language=XML, 
basicstyle=\small, frame=single]
<element name="existsResponse">
<complexType>
<sequence>
  <element name="existsReturn" type="xsd:boolean"/>
</sequence>
</complexType>
</element>
\end{lstlisting}

So the client knows that when this method is called a boolean type is returned.

Finally, at the end of the \emph{WSDL} file the address of the web service can be found. This means that the \emph{WSDL} does not necessarily 
has to be in the same server as the web service. When the client takes the Web service's description file he knows where the real service is, 
the address location field.

\begin{lstlisting}[captionpos=b,label=ws-wsdl_target, caption={\textit{Web Service Location}},language=XML, basicstyle=\small, frame=single]
<wsdl:service name="FFLocationAPIService">
<wsdl:port binding="impl:FFLocationAPISoapBinding"
                                name="FFLocationAPI">
<wsdlsoap:address location="http://localhost:8080/
                    fflServer/services/FFLocationAPI"/>
</wsdl:port>
</wsdl:service>
\end{lstlisting}


\subsection{Serialization/Deserialization}
In this section we are going to see how method calls, their parameters and their returned values are serialized and deserialized. We will use 
\emph{soapUI Pro 3.6} to invoke methods in the web service. After loading this program we create a new project. We are asked to input the 
\emph{WSDL} file's url. When press "\emph{OK}" the application is going to get the \emph{WSDL} file that contains the information of everything 
the web service has to offer and create empty \emph{SOAP} messages, like \emph{XML} templates, in in order to be filled by the user.

The application knows from the \emph{WSDL} file where to call the methods, in which workspace, with which parameters and which is going to be 
the response. This way the application offers transforms \emph{SOAP} messages in \emph{XML} format for each method.

For example we are going to test the web service's login method. Let's say we already have a registered account, the nick is "\emph{nick}" and 
the password is "\emph{password}". We fill the "\emph{nick}" and "\emph{pw}" in order to get an authentication object. We know that the web 
service asks for the password hashed with the \emph{SHA} algorithm so we introduce the \emph{SHA} hash function of our password "\emph{password}".

\begin{lstlisting}[captionpos=b,label=ws-login_xml, caption={\textit{SOAP Login request}},language=XML, basicstyle=\small, frame=single]
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/
                soap/envelope/" xmlns:con="http://controller">
  <soapenv:Header/>
  <soapenv:Body>
    <con:login>
      <con:nick>nick</con:nick>
      <con:pw>5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8</con:pw>
    </con:login>
  </soapenv:Body>
</soapenv:Envelope>
\end{lstlisting}

When we press the play button the \emph{soapUI} application is going to send this \emph{SOAP} message in \emph{XML} over \emph{HTTP} to the 
\emph{URL} that was specified in the \emph{WSDL} file. In that url the \emph{Tomcat} server is supposed to be listening to new requests, when 
this message arrives is going to deserialize it. This means that real \emph{Java} objects, in this case two strings(nick and password) are 
created and the method login called in the server. This method is going to create a new authentication object \emph{Auth} that will be returned.

\begin{lstlisting}[captionpos=b,label=ws-login_response, caption={\textit{SOAP Login response}},language=XML, basicstyle=\small, frame=single]
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/
      soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <loginResponse xmlns="http://controller">
      <loginReturn xsi:type="ns1:Auth"
        xmlns:ns1="http://controller">
        <ns1:session xsi:type="xsd:int">618357913</ns1:session>
        <ns1:userID xsi:type="xsd:int">5</ns1:userID>
      </loginReturn>
    </loginResponse>
  </soapenv:Body>
</soapenv:Envelope>
\end{lstlisting}

Now the \emph{Tomcat} server has the \emph{Auth} object, so as to be returned it should serialize it and send it back by using the same SOAP 
message protocol through the same socket. So now the client that did the request, the \emph{soapUI} application, receives this message.
In this message we can see how the \emph{Auth} authentication object has been serialized into the \emph{SOAP} message. The auth object has two 
fields, the \emph{session} variable and the \emph{userID}. Now on the client has a valid authentication object that can send to invoke other 
methods in the web server. Using this authentication object we call the \emph{myUser} method in order to get our own user information. Our own 
now means the logged user's information, the one that logged in and got the authentication object that is associated now to him.

So using \emph{soapUI} we invoke the \emph{myUser} method with the authentication object serialized.

\begin{lstlisting}[captionpos=b,label=ws-myuser_request, caption={\textit{SOAP myUser request}},language=XML, basicstyle=\small, frame=single]
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/
                soap/envelope/" xmlns:con="http://controller">
  <soapenv:Header/>
  <soapenv:Body>
    <con:myUser>
      <con:a>
        <con:session>618357913</con:session>
        <con:userID>5</con:userID>
      </con:a>
    </con:myUser>
  </soapenv:Body>
</soapenv:Envelope>
\end{lstlisting}

As we can see in the returned \emph{SOAP} message a \emph{UserInfo} object is returned. The server has deserialized the authentication 
object, got the owner's identification and returned his user information object.

\begin{lstlisting}[captionpos=b,label=ws-myuser_response, caption={\textit{SOAP MyUser response}},language=XML, basicstyle=\small, frame=single]
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/
    soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <myUserResponse xmlns="http://controller">
      <myUserReturn xsi:type="ns1:UserInfo"
                    xmlns:ns1="http://model">
        <address xsi:type="xsd:string">address</address>
        <administrator xsi:type="xsd:boolean">false
              </administrator>
        <country xsi:type="xsd:string">country</country>
        <email xsi:type="xsd:string">email@email.com</email>
        <id xsi:type="xsd:int">5</id>
        <name xsi:type="xsd:string">name</name>
        <nick xsi:type="xsd:string">nick</nick>
        <phone xsi:type="xsd:int">123456732</phone>
        <position xsi:type="ns1:Position">
          <date xsi:type="xsd:string">2010-12-13 13:02:23.0
                    </date>
          <latitude xsi:type="xsd:string">66.3777
                </latitude>
          <longitude xsi:type="xsd:string">-23.1038
                </longitude>
        </position>
        <surname xsi:type="xsd:string">surname</surname>
      </myUserReturn>
    </myUserResponse>
  </soapenv:Body>
</soapenv:Envelope>
\end{lstlisting}

Something worth mentioning is, that in the client side this serialized object can be also be mapped into objects, deserialized. Like it will 
be done in the android and in the web site, using the appropriate \emph{Soap libraries}.

Finally, we have to think about the photos, and how to serialize them into the \emph{XML} messages. Photos are binary arrays, this means that 
can not be serialized that easily in the \emph{SOAP} message. The standard says that the binary arrays has to be encoded in \emph{Base64} in 
order to be serializable into this messages. Due to different reasons, like having control of the encoding system in the web service, it's 
decided to do it manually. This means that the web service is going to encode the byte array into a string, instead of being the \emph{Tomcat} 
server that has to implement this. The \emph{Photo} class is going to take care of this, making it transparent to the user.
